Revision: tla--libawk-exp--1.3.1--patch-1
Archive: lord@emf.net--libawk-exp-2005
Creator: Thomas Lord <lord@emf.net>
Date: Fri Feb 11 10:33:57 PST 2005
Standard-date: 2005-02-11 18:33:57 GMT
Removed-files: libawk/numbers.c libawk/numbers.h
Modified-files: libarch/apply-changeset.c
New-patches: lord@emf.net--libawk-exp-2005/tla--libawk-exp--1.3.1--patch-1
Summary: remove libawk/numbers.[ch]
Keywords: 

NOTE: this change modifies `libarch/apply-changeset.c'

Tests performed (one platform): `make', `make test', 
                                changeset burn-in tests

`./libawk/numbers.[ch]' defined a single function, `int_to_string',
which converted a non-negative `int' value to a `malloc'-ed,
0-terminated, decimal string.   Upon a failed allocation, this
function would exit the process (via `panic').   This function
called hackerlab's `cvt_ulong_to_decimal', passing it a very large
output buffer, but formally speaking would buffer overflow if
`sizeof(int)' were sufficiently large.

`int_to_string' had only one call, in one caller
("libarch/apply-changeset.c(set_aside_shuffled_dirs)").

The call in `set_aside_shuffled_dirs' has been replaced with a direct
call to `cvt_ulong_to_decimal_n', eliminating the possibility of a 
buffer overflow.   A very large buffer is still used, but output
to that buffer is bounds checked.   If for some very strange reason
the buffer is too small, an `invariant' is now violated in
`set_aside_shuffled_dirs'.

A compile time check has also been added to `apply-changeset.c':
if at compile-time it appears that the output buffer passed to
`cvt_ulong_to_decimal_n' could possibly be too small, a `#error'
pre-processor directive is reached.  This check justifies the
`invariant' that watches for buffer-overflow at run-time.

This change eliminates two source files and a needless call to
`malloc'.

This change makes little difference in `apply-changeset.c' -- the
file's length is almost unchanged and the code is, if anything,
slightly clearer and less error prone.

This change eliminates a call to `panic' in the event of allocation
failure and, in that sense, is a small step in the direction of
"librification" of `libarch'.

